@Phaiax Could you tell us more about the motivation of this change?

cc @alexcrichton I'm not sure if this would work well with the plan to integrate this into rust-lang/rust. In fact, I've seen integration errors before because this crate uses gcc 0.3.35 and the crates in rust-lang/rust use an older version.

The readme recommends

[dependencies.compiler_builtins]
git = "https://github.com/rust-lang-nursery/compiler-builtins"
features = ["c"]

But this does not work seamlessly for user projects without some recent changes to gcc.

Edit: Does cargo unify crate versions of build-dependencies?

But this does not work seamlessly for user projects without some recent changes to gcc.

Do you mean that there some targets for which this crate doesn't compile?

I'd prefer to use a newer gcc release. We just have to bug @alexcrichton to release a new one.

Edit: Does cargo unify crate versions of build-dependencies?

It should.

Yes, the build of the libcompiler-rt uses cc instead of arm-none-.....

You can e.g. set CC_thumbv6m_none_eabi=arm-none-eabi-gcc to override the default compiler (cc). The gcc crate is not guaranteed to always correctly guess the compiler; it just has some heuristics to guess the prefix based on the target triple.

I know. But I think it was not intended this way :D
Best would be to use the override in the .cargo/config file. But that is ignored for compiler_builtins.

[target.thumbv6m-none-eabi]
linker = "arm-none-eabi-gcc"
ar = "arm-none-eabi-ar"

We just have to bug @alexcrichton to release a new one.

Done!

Done!
Thank you, @alexcrichton!

@bors r+
@Phaiax note that if we need to downgrade gcc to integrate this into rust-lang/rust, we'll do that.

📌 Commit 56dc20a has been approved by japaric

⌛ Testing commit 56dc20a with merge 600ed3b...

☀️ Test successful - status-appveyor, travis
Approved by: japaric
Pushing 600ed3b to master...